ENH: EA._cast_pointwise_result #62105
Conversation
jbrockmendel
changed the title
|
The pyarrow duration stuff is caused by an upstream issue apache/arrow#40620 |
jbrockmendel
changed the title
|
@rhshadrach i think you had a recent issue/pr involving retaining nullable dtypes in a .map? |
There was a problem hiding this comment.
Really great improvement here. It seems to me there are two potential situations we might find ourselves in: (a) take the dtype of self into account or (b) don't take the dtype of self into account. I highlighted one specific example below where I think this might go awry. The base implementation is doing (b) whereas the subclasses are doing various degrees of (a). Understand that isn't being introduced here, but I think the long term goal is to make this more consistent?
For now, do we want to setup the framework to separate these two cases out somehow - perhaps an argument to _cast_pointwise_result?
I see now that this is just preserving the dtype when possible. I think we don't need two different cases as I first imagined.
| @@ -282,33 +281,10 @@ def _create_arithmetic_method(cls, op): | |||
| DecimalArrayWithoutCoercion._add_arithmetic_ops() | |||
|
|
|||
|
|
|||
| def test_combine_from_sequence_raises(monkeypatch): | |||
There was a problem hiding this comment.
its impossible to make this test work since it defines _from_sequence to always raise. which strikes me as an unnecessary case to test.
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.Still have a bunch of pyarrow tests involving duration/timestamp dtypes failing. Also need to update/remove the test files' _cast_pointwise_result methods.
xref #56430, could close that with a little effort.
I suspect a bunch of "pyarrow dtype retention" tests are solved by this, will update as I check.Nope!